@OR13, are you suggesting the existing feed property (tstr) moves to a named property under reg_info?

Protected_Header = {
1 => int ; algorithm identifier
3 => tstr ; payload type
4 => bstr ; Key ID
; TBD, Labels are temporary
391 => tstr ; DID of Issuer
392 => tstr ; Feed
393 => Reg_Info ; Registration Policy info
}

Reg_Info = {
  ? "feed_id": tstr,
  ? "register_by": uint .within (~time),
  ? "sequence_no": uint,
  ? "issuance_ts": uint .within (~time),
  ? "no_replay": null,
  * tstr => any
}

Or, are you saying SCITT doesn't have a well known feed property, and consumers need to decide their own name/value pairs within the Reg_Info?

I very much prefered a world in which makers of statements MUST idenfify a feed. Knowing that there is some specific field that consumers and producers are using to co-ordinate the context of their statements lets me, as a TS implementor, organise data much more conveniently.

I get this benefit without having to care a lot about exactly what form the feed id has. From my PoV it is just a tuple [DID, feed id]. I don't care that many issuers may make statements about the same feed id.

If I understand this change correctly, moving to reg info seems to make its presence optional ? And so I would have to start understanding where all the different issuers chose to make their equivlent of feed id known.

It's presense as a MUST does not require a strong opinion re what form it takes. I believe the standard would be much more practical and useful if the field was mandatory but its content were left to applications with some guidance from profiles.

Feed was previously defined as a string separate from reg info.

After this PR is merged you could add feed as a new property of reg info, along with guidance on its use, or leave it unspecified which would essentially be equivalent to what the spec says now.

Since the structure of feed is not defined, this PR doesn't impact interoperability.

Issuers might prefer to use different expressions of feed in reg info, for example cpe and gtin... what happens if they want to include both?

What about all 3 { feed, cpe, purl } ?

Removing feed doesn't prevent properties from being added to reg info and as has been discussed at great length, feed isn't the only member of the protected header that transparency services can index on.

Removing feed from the protected header also makes room for using feed to describe the index exposed by the transparency service without confusing that with the topic identifier the issuer included in reg info.

Since the structure of feed is not defined, this PR doesn't impact interoperability.

Ah, this is where we differ. I see its presence and its definition as 'an opaque statement issuer identifier' as crucial from the perspective of practical applications and interoperability. Without it the context of statements seems entirely arbitrary.

Issuers might prefer to use different expressions of feed in reg info

They are welcome to do so, and I can see plenty of places that could be useful. I see that as supplimentary to the basic utility of a feed identifier as a co-ordination context.

Removing feed doesn't prevent properties from being added to reg info

Neither does keeping it think ?

has been discussed at great length,

I understood the issue with feed was the attempt to make it more structured than an 'opaque issuer defined value'. I see the attempt at adding mandatory structure, possibly even 'strongly recommended' structure as undermining the applicability of the standard.

feed isn't the only member of the protected header that transparency services can index on.

Ok, great, what do you think is more appropriate here, what am i missing ?

@OR13 I beg to differ. Feed should not be part of RegInfo

The reason I see it this way is:

1. Feed is an additional information about the Statements made for the Artifact, How issuer would like to identify all the Statements pertaining to the Artifact. It has All Statements Scope (about an artifact)
2. Registration Information container is for about the registration specific aspect of the specific command, When it was registered. Till what time it has a validity etc. It has per Command Scope.
3. We should not link the two as the scope is different!
4. Any other comments are Welcome!

FWI:

When I saw 'feed' in the earlier work presented as just a string it struck me as a simple, powerful and practical way to have a base line context for statements.

When I got a sense of the efforts to add structure to it I didn't think happy thoughts. I just couldn't see how there could be 'one way'.

If it moves the world forward to stop talking about it and leave it out, we can of course work with that. It could always come a long later if it is realy as useful as I think it is.

It does seem to mean that trusted service implementations will all be inventing different ways to contextualise statements. Possibly that is actually the right thing, and scitt users should be aware of the specifics of each TS.

The presence of feed as 'a string' seemed to offer a really good baseline - as long as it didn't try to be opinionated about structure.

RegInfo is about feed... because it will be used to order the feed by the ts..the RDF style feed, would look like:

feed: {
id : // graph node id
type: // graph node type
... }

The whole idea of registering something is to be able to come back and see filtered views of what has been registered.

Since feed has no structure, it is extraneous to reg info.

Perhaps an alternative PR will propose an informative way that the transparency service processes feeds, maybe something like:

select * from feeds where feed.id = device.id

But the same thing can already be accomplished by indexing on any of the other custom properties the ts registration policy allows.

Another alternative would be to make the registration policy normative and require feed to be present.

I'm open to other solutions, let's see some PRs :)

This PR could be merged first, then #108 could address the CDDL changes, and #107 could be updated to find replace "Feed" with "Subject" / "sub" and or tag 2.

The purpose of the feed​ header is to allow a single issuer iss​ to sign for different purposes.

For example:

• A Microsoft product group may have a single iss​ identifier. That product group may produce a collection of software products, each packaged as a container. Each of those containers has a different purpose. The product group can indicate that purpose in the feed​. When a new container image for feed​ "my-https-front-end" is produced, the signed statement for it can be distinguished from the signed statements for the "my-database-connector" container image (and all of its versions).
• An operator of an online service single iss​ identifier. That operator may produce a series of signed statements regarding the software they run with feed "our-software-product" and, separately, a series of signed statements regarding which versions of their software customers should currently be using, with feed "our-software-usage-policy".
• A foundation that produces an open source library may have a single iss​ identifier. That foundation might release a series of signed statements for their x86 binaries with feed "oss-library-x86-64" and a separate one for ARM binaries with feed "oss-library-aarch64".

Without a header that indicates the purpose of the signed statement, there is a confusion attack. For example:

• An online service provider may intend to run a "my-database-connector" container from some issuer. Due to a malicious confusion attack, they are given signed statements for a "my-database-connector-with-debug-backdoor" container.

In other words: without a feed​, an iss​ can only be used for a single purpose.

The name feed (as opposed to, say, purpose) is to indicate that the signed statements may be augmented or superceded with additional signed statements for the same purpose. For example, a software product may have a new version released for the same feed.

As other already mention I feel the need to have an identifier that MUST be present to differentiate between different products within the same issuer.

This PR could be merged first, then #108 could address the CDDL changes, and #107 could be updated to find replace "Feed" with "Subject" / "sub" and or tag 2.

In my understanding your suggestion here is to separate the concept of an identifier, which would be the sub field of the CWT claim and the concept of the feed which would allow more complex references between various statements. If this is the intended behavior, than I agree this could be the way to proceed.

@sylvanc So according to your definition a Feed is an information about a Product. it is not clear to me whether the Feed identify a specific revision of the product or it associates to any/all revisions of a product.
Then if it pertains to a all revisions, then how a statement about a specific revision can be identified ?

Do we need to recommend the same in the Architecture document ?

Also the existing Feed definition implied, multiple issuers can use the Feed to identify statements pertaining to an Artifact.

We need to clearly define, 1. Purpose 2. Scope 3. Usage examples of Feed before introducing into the specification.

Otherwise, it triggers confusion/ambiguity in the Specification.

I recommend we Remove Feed from the existing specification, come up with a clear proposal which defines 1.2. & 3. above and then re-introduce the same

No, feed is not a product. A feed identifies an unbounded sequence of statements about the same topic. It is a purpose, with the explicit ability to continue to make new statements for that purpose.

A signed statement is meaningless without both an issuer iss and a feed. Removing it creates a situation where a relying party must do a "deep dive" of the payload in order to guess at the statement's purpose.

Multiple Issuers, X, Y,Z are making statements about the same product P.

This resonates with me, as it accomplishes the scenarios entities do today.

An Issuer : X is issuing statements about Multiple products (P, Q, R):

This one is less clear. Can we articulate how the above could be used in practice? Trying to correlate across multiple Artifacts (products as noted above) feels like a conflation and complication. Rather than attempt to make a statement about multiple artifacts, why not make the statement on each artifact?

A feed identifies an unbounded sequence of statements about the same topic. It is a purpose, with the explicit ability to continue to make new statements for that purpose.

This seems consistent with: Attempt clarification of Feed purpose and differentiate from reg_info #107

If we can ground the designs in the problems we're trying to solve, (the use cases) we might be able to better address a proposal.
From: Use CWT Claims in Headers: comment

The thing I'd like to test with this discussion is whether two or more identities can make statements about the same artifact.

1. Wabbit Networks (the identity 391: did) releases their net-monitor v1 software (the Artifact)
2. Wabbit Networks publishes a Signed Statement using a "392: feed": "wabbitnetworks-netmonv3linux and "391: DID":="wabbitnetworks" on their scitt.wabbit-networks.io service.
3. Wabbit Networks has an auditor publish a signed statement: "392: feed": "wabbitnetworks-netmonv3linux and "391: did":="coyote-security" on the same scitt.wabbit-networks.io service.
4. Cosmic security, Mitre, and other independent publishers make statements about the same Artifact
   • "392: feed": "wabbitnetworks-netmonv3linux and "391: did":="cosmicsecurity" on their scitt.cosmic-security.io service.
   • "392: feed": "wabbitnetworks-netmonv3linux and "identity":="mitre" on their scitt.mitre.org service.

As a consumer, ACME Rockets can

• query the scitt.wabbit-networks.io service, to get statements associated with the net-monitor v1 software package.
• query scitt.mitre.org for any public statements, using "392: feed": "wabbitnetworks-netmonv3linux as the means to find statements from Mitre for the Wabbit Networks, net-monitor v1 software.
• optionally query scitt.cosmic-security.io as they specialize in aerospace software, providing deeper insights for the specific aerospace vertical.

ACME Rockets (the consumer) can choose to trust the statements because they trust the independent identities making statements. Which endpoints they query is up to them. They could equally choose to NOT trust Coyote Security, (because who trusts the Coyote?), or because they're not tailored to the unique needs Cosmic Security addresses.

In the above case, 392: feed is used to independently identify a collection of statements about an artifact, independently from the identity, and consistent across SCITT Transparency Service Instances

Is the above usecase one we're trying to solve?

• If not, what is the problem we're solving, and how would someone implement the above?
• If so, does 392: feed and 391: did solve the problem? If not, what are the alternatives?

That's a great use case. Yes, any iss can make a statement with a given feed. But feed isn't a "controlled" or "owned" value - no need for registering it. The tuple of (iss, feed) identifies the sequence of statements from an issuer - which works well with your Coyote example.

Fixes #11

I'm withdrawing this PR, however I may object to the current text in future published revisions.

I look forward to reviewing the next draft.